A secure element, for example a smart card, typically takes the form of a microcircuit integrated in a removable way into a host electronic device, or, in a variant, embedded (by soldering, for example) in an electronic device. By way of example, a secure element may be an eSE (“embedded secure element”) or an eUICC (“embedded Universal Integrated Circuit Card”).
A secure element comprises a processor which is specific to it, being different from the processor of the host electronic device in which it is integrated or embedded, and comprises a nonvolatile memory for storing computer programs that can be executed by the processor.
A non-modifiable area of the nonvolatile memory stores what is known as an “initial” or “base” program, usually of small size, for example a boot program (known as a “boot loader”) stored by the manufacturer of the secure element. The initial program provides functionality enabling an intermediary such as an operator or a supplier of secure elements to users to customize the secure element, by loading software elements, usually consisting of compiled or interpreted code (that is to say, code words or “bytecodes” in machine language or code, directly executable by a processor), such as an operating system or applications, into a special area of the nonvolatile memory defined by the initial program. This initial program is, for example, associated with a particular operating system comprising, notably, a port control module for communication with this initial program, a memory update control module, a command interpreter, and security modules for securing this initial program. This particular operating system is customized by the manufacturer of the secure element, and no modification of the system is permitted after customization.
As a general rule, this initial program is the first program executed when the secure element is started, that is to say before any other program which may be present in the memory of the secure element. This program is essential for the execution of other programs in the secure element.
The aforesaid special area of the nonvolatile memory is entirely controlled by the initial program, which is the only program that can modify the boundaries of the special area or its content.
More precisely, these boundaries may be stored in registers of the initial program, or alternatively may be the result of the execution by the initial program of commands defining them. In all cases, the definition and any modification of the boundaries can only be the result of an action of the initial program.
Furthermore, only the initial program can activate (or deactivate) the special area for the purpose of enabling (or prohibiting) the execution of its content.
The aforesaid area is normally used for storing compiled or interpreted code, and will therefore be referred to hereafter as the “code storage area”. It is particularly important that the code storage area should not be modified during the execution of the software elements that it contains, in order to ensure the integrity of the applications and operating system used by these software elements in the secure element.
During the life of the secure element, other software elements may be loaded into the code storage area. These may be, for example, a new version of a software element already stored (an update of the software element) or new data. In order to ensure the integrity and legitimacy of these software elements subsequently loaded into the code storage area, verification mechanisms are used, typically by the initial program, before activation, that is to say before enabling execution.
For example, the document FR 2 993 682 describes a boot program executed when the secure element is started up, enabling the code of a new version of an operating system to be obtained from an updating device when the installed operating system becomes obsolete. The integrity of the code of this new version of the operating system is verified by the boot program, one code block at a time, and as a whole, before the activation of the new version of the operating system is enabled.
However, the integrity verification only relates to newly received and loaded software elements.
Thus, a software element of the malicious type (known as “malware”), stored in the code storage area by a malicious party before the loading of a new software element, is not detected by the boot program during this integrity verification, because the boot program only relates to the newly loaded software element. Consequently there is a lapse in security.
There is also a lapse in security if a malicious party modifies or damages, by laser attack for example, a software element already stored in this code storage area. This is because the integrity verification performed on newly loaded software elements cannot reveal this modification or damage to the content of the code storage area.
Thus there is a need to improve the control of the securing of the secure element, and notably of the integrity of the software elements when data are loaded into this storage area.